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REMARKS/ARGUMENTS 

The Office Action of July 25, 2006, has been carefully reviewed and these remarks are 
responsive thereto. Claims 1-37 and 39 remain pending and allowance of the instant application 
are respectfully requested. 

Claim Rejections Under 35 U.S.C §103 (a) 

Claims 1-6, 8-19, 20-26, 28-29, 31-36, and 39 were rejected under 35 U.S.C. §103(a) as 
being unpatentable over Bertrand et al. (U.S. patent No. 6,687,252, hereinafter "Bertrand") in 
view of Takeda et al. (U.S. Publication No. US 2001/0048686 Al) and further in view of 
Applicant's admitted prior art (as found in Applicant's specification at paragraph 8). This 
rejection is respectfully traversed for the following reasons. 

Independent claims 1, 8, 20, 28, 31 and 32 all relate to, inter alia, a GGSN assigning one 
of a private network address and a public network address to a mobile station based on 
information contained in an APN field of a Create PDP Context Request message. The 
information contained in the APN field is transmitted by the requesting mobile terminal and 
relates to a request for one of a private network address and a public network address. As 
recognized in the Office Action, neither Bertrand nor Takeda, either separately or in combination, 
teaches or suggests such a feature. While Bertrand and Takeda both disclose an APN field, 
neither one teaches or suggests that the assignment of a private or a public network address is 
based on information in the APN field related to the request by the mobile station. Neither 
Bertrand nor Takeda provides any independent motivation or suggestion to combine the use of 
APNs with the assignment of network addresses in the manner suggested by the Applicant. 

Additionally in Takeda, it is the DHCP server that assigns the IP address to the mobile 
terminal, not the gateway node. P. 6, f 95. Even so, Takeda does not teach or suggest that the 
DHCP, in allocating IP addresses, evaluates or receives any information contained in the APN 
relating to the mobile terminal's request for one of a public network address or a private network 
address. Neither Bertrand nor Takeda provides any independent motivation or suggestion to 
combine the use of APNs with the assignment of network addresses in the manner suggested by 
the Applicant. 
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Paragraph 8 of Applicant's Background of the Invention does not remedy these 
deficiencies in Bertrand and Takeda. Paragraph 8 describes the use of a Network Address 
Translator (NAT). A NAT is used when a host that is assigned to a private address within an 
administrative domain intends to send an IP address (and possibly other selected fields within the 
datagram) into a public IP address prior to the IP datagram being sent outside the administrative 
domain associated with the NAT. A NAT transforms a private IP address (and possibly other 
selected fields within the datagram) into a public IP address prior to the IP datagram being sent 
outside the administrative domain associated with the NAT. Similarly, when an IP datagram is 
sent from a host that is outside the administrative domain associated with the NAT to a host with 
a private address, then the NAT transforms a public IP address to a private address. 

A NAT does not conserve public IP addresses and simultaneously maintain end-to-end 
security and application friendliness. Indeed, as explained in paragraph 11 of the present 
application, there are two major drawbacks to associated with the use of a NAT. The first major 
drawback is that the NAT-based approach breaks the end-to-end security model by changing the 
destination address of a datagram and thereby invalidating the authentication header of the 
datagram. The second major drawback is that certain types of applications cannot work in the 
presence of a NAT, unless remedial measures are taken, such as the inclusion of an application 
gateway (proxy). For example when an IP address is embedded into an application protocol unit 
(PDU), and ALG (Application Level Gateway) is required so that the embedded IP address is 
changed because a conventional NAT-based address assignment operation will not change the 
embedded IP address. 

As explained in paragraph 12 of the present application, in order to overcome the 
disadvantages associated with NATs, i.e., the security break and the "unfriendliness" toward 
some applications, a mechanism commonly referred to as Realm Specific IP (RSIP) has gained 
significant support within the Internet Engineering Task Force (IETF). As noted in paragraphs 
13-17 of the present application, RSIP protocol makes use of a NAT uimecessary, and thereby 
avoids the drawbacks involving NATs. 

In view of the drawbacks involving NATs, and the teaching away of using NATs by using 
RSIP protocol, one of ordinary skill in the art would not be motivated to incorporate a NAT into a 
combination of Bertrand and Takeda to provide the present invention. Even if a NAT is 
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incorporated into a combination of Bertrand and Takeda, the combination of the three references 
would not result in the present invention. A NAT does not involve a Create PDP Context 
message having an APN field containing information relating to a request for one of a private 
network address and a public network address. Rather, a NAT simply transforms a private IP 
address into a public IP address when a host intends to send an IP datagram to a host that is 
outside the administrative domain of the sending host. 

The Office Action may not use Applicant's invention as a blueprint for combining distinct 
components/features found in Bertrand, Takeda, and a NAT as described in paragraph 8 of the 
present application. As such, claims 1, 8, 20, 28 and 32 are allowable for at least this reason. 

Claims 2-7, 9-19, 21-27, 29, 30 and 33-37 are allowable for at least the same reasons as 
their respective base claims and further in view of the novel and non-obvious features recited 
therein. For example, claims 3, 15, 23 and 33 relate to, inter alia, information contained in the 
APN field of the Activate PDP Context Request message explicitly indicating one of a private 
network address and a public network address. As discussed on p. 13 of Apphcant's 
specification, the inserted information (in the APN field) relating to whether a public or a private 
address assignment is desired can be an explicit indication, such as a particular bit (or bits) of the 
APN field being set, such as is claimed in claims 3, 15, 23 and 33. Neither Bertrand nor Takeda 
nor a NAT, separately or in combination, teaches or suggests such a feature. The Office Action 
even admits this deficiency of Bertrand and Takeda. Instead, the Office Action alleges that If 26- 
27, 71-72, and 89-90 of Takeda disclose an "an Activate PDP Context Request message and a 
Create PDP Context Request message that have an APN field containing information relating to a 
request for an address." Even assuming the validity of such an allegation, merely containing 
information relating to a request is distinguishable from containing information in the APN field 
explicitly indicating one of a private network address and a public network address. Significantly, 
the cited passages only disclose an APN for identifying a gateway node. There is no teaching or 
suggestion that the APN field includes any explicit indicators of whether a private network 
address or a public network address is being requested. Claims 3, 15, 23 and 33 are thus 
allowable for this additional reason. 

Claim 39 recites, inter alia, "the Activate PDP Context Request message having an APN 
field containing one or more parameters indicating a type of requested network address, wherein 

Banner & Witcoff, Ltd. -4- 
10 S. Wacker Drive, Suite 3000 
Chicago, IL 60606 
(312) 463-5000 



Appln.No. 10/017,398 
Amendment dated October 4, 2006 

Reply to Office Action of July 25, 2006 PATENT 
the type is one of a private network address and a public network address." Neither Bertrand, 
Takeda, Applicant's admitted prior art regarding NATs, separately or in combination, teaches or 
suggests such a feature. Although both Bertrand and Takeda disclose APNs, neither teaches or 
suggests that the APN contains a parameter indicating a type of requested network address. In 
fact, nowhere does Bertrand or Takeda disclose that a mobile terminal can request a specific type 
(i.e., private or public) of network address. Applicant's admitted prior art regarding NATs do not 
remedy this deficiency in Bertrand and Takeda. Claim 39 is thus allowable for at least this 
reason. 

Claim Rejections Under Boudreaux 

Claims 7, 19, 27, 30 and 37 were rejected under 35 U.S.C. §103(a) as being unpatentable 
over Bertrand in view of Takeda and Applicant's admitted prior art on NAT as applied to claims 
1-6, 8-18, 20-26, 28-29, 31-36 and 39 above, and further in view of Boudreaux (U.S. Patent No. 
6,466,556. This rejection is respectfully traversed for the following reasons. 

Claims 7, 19, 27, 30 and 37 all relate to a GPRS-based communications network that is a 
Universal Mobile Telecommunications System. The Office Action, on page 16, concedes that 
Bertrand and Takeda and Applicant's admitted prior art does not disclose such a feature. While 
Boudreaux may teach a Universal Mobile Telecommunications System, it does not remedy the 
failure of Bertrand, Takeda, and Applicant's admitted prior art to teach the claimed invention of 
the independent claims upon which 7, 19, 27, 30 and 37 depend from. As such, claims 7, 19, 27, 
30 and 37 are allowable for over the proposed combination of Bertrand, Takeda, Applicant's 
admitted prior art regarding NAP, and Boudreaux. 

CONCLUSION 

All rejections having been addressed. Applicants respectfully submit that the instant 
application is in condition for allowance, and respectfully solicits prompt notification of the same. 
However, if for any reason the Examiner believes the application is not in condition for allowance 
or there are any questions, the Examiner is requested to contact the undersigned at (312) 463- 

5405. 
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Respectfully submitted, 




Dated: October 4, 2006 



By:. 



Robert H. Resis 
Registration No. 32,168 
BANNER & WITCOFF, LTD. 
10 South Wacker Drive, Suite 3000 
Chicago, IL 60606 
Direct Dial: 312-463-5405 
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